For most of this year I've been working mainly on a Macbook Pro, having deserted my Ubuntu desktop.  Somebody wrote to me recently, kindly enquiring how this life was going, and asking some questions in particular.

Although of limited interest to some, I decided to answer the mail here, if for nothing else to record my views for future reference.

Q: How is developing on a Mac? Is TextMate really that good?

Developing Rails applications on a Mac is sweet, and yes, TextMate really is that good. My jilted .emacs languishes in lonely misery.

Developing other (non-Mac) stuff on a Mac is a real pain however, because nothing's where you'd expect it after years of Linux use.  Like several other developers I've seen, I run Ubuntu Linux in a virtual machine under Parallels for such work.

It's not just that Macs lack apt-get (as you can get it with fink), it's that they lack the reliability of Debian or Ubuntu's package repositories to underpin it. Running Linux in a virtual machine is far easier.

On the subject of TextMate,  perhaps the best compliment I can pay it is that using it reminds me of the last text editors I really felt at home in, CygnusEd and then FrexxEd on the Amiga. TextMate's most serious flaw is the inability to create split views, however. It seems to me that's a key programmers' feature, to be able to read from one source file at the same time as editing another.

Q: Is the hype about Ruby on Rails true?

I still think so. I resisted it for 6 months because I tend to be averse to anything that gets such a large amount of publicity, but then stepped aboard the train around the time of Rails 0.13.

I've not really looked back after my initial experiments seemed to bear out the claim of developing "ten times faster than PHP". I'll admit I find it hard to keep up with all the extra developments that get added at the Rails cutting edge, but then again I don't really need them.  Most of those additions are refinements, rather than core changes. Constraints on my time mean I tend to write in a common Rails subset, as opposed to flexing my muscles with the obscure but clever bits.Even if your taste isn't for Rails, then the trend that Rails, Django and friends have started is improving the web development playing field for all.

Q: What makes you happy and sad about the Mac?

The things that the Mac still scores on are:

• Fonts, fonts, fonts. Despite all my many efforts at getting good letterforms on Linux, I still couldn't make it as good as OS X.
• Productivity applications. I love my OmniGraffle and OmniOutliner. I'm salivating over the prospect of OmniFocus, and Quicksilver rocks my world.
• Hardware. Suspend/resume without worry, video conferencing that works.

The interesting thing to me is that none of these are very difficult to surmount, for want of a little resource.  The day of the Linux desktop, so perennially around the corner, will yet come.

As a balancing postscript, I will mention that there are some things that are Mac irritants to a sensible Linux person, which include filesystem case sensitivity, lack of decent SSH agent (yes, I've tried them all), not knowing what to kill -9 when things go pear-shaped, Apple's arrogance, crippled nature of some default apps (iChat won't put multiple accounts in the same window, Safari doesn't support keyboard navigation at all well, Quicktime player won't play movies fullscreen).

I deploy my Rails applications with Capistrano to an Ubuntu machine, which uses the excellent Debian style layout of Apache 2 configuration files. To keep things tidy, I like to place the Apache configuration file inside the config directory of the Rails project, along with the rest of the configuration for the Rails application and Mongrel. With the help of a couple of Capistrano rules I can then ensure that, on deployment, the latest Apache configuration file is also sent to the server:

# after setup, do a one-time link in
task :after_setup do
  sudo "ln -nfs # current_path /config/# application         
     /etc/apache2/sites-available/"
end
# cause apache2 to re-read. you probably have this rule anyway
task :restart do
  # if you're running mongrel_cluster, uncomment the following line
  # restart_mongrel_cluster
  sudo "/usr/sbin/apache2ctl graceful"
end

The first time round you'll probably want to do a2ensite yourapp manually, but this could easily be added into the after_setup rule. Not rocket science, but a pleasing bit of configuration that keeps things tidy.

I can't get enough of the bzr revision control system, and I'm quite fond of Rails too. So, I thought I'd share my deployment setup for Rails applications using Capistrano and bzr. Capistrano works on the assumption that you're deploying from a revision control system. Secondly, it requires that your deployment server is aware of how to access this system. This leaves you with various options, the most obvious of which are:

1. Host your source repository on your deployment server
2. Have your deployment server equipped with remote access to your source repository
3. Mirror your repository to your deployment server

Of these, option 1 is out for all but somewhat casual projects, option 2 either opens up your source repository more than I like, or needs fiddly tunnelling of SSH which I don't think Capistrano is up to yet (I only like to use key-based access with SSH, rather than password based access, which seems at the moment complicate life where Capistrano is concerned.) I've opted for option 3. The pattern I use is this. On setting up the deployment server, I push a copy of the bzr repository to a private directory. Then, on deployment I first update that repository securely from the master repository inside my network, then export the new release locally on the server. Here are the relevant bits of my Capistrano configuration:

set :repository, "/opt/repo_mirror/# application "

…

set :scm, :bzr
set :checkout, "branch"

…

task :before_update_code do
   bzr push sftp://deploy.example.org/opt/repo_mirror/# application 
end

One big advantage of this over option 2, a remote source repository, is that only the changes are sent up to the server, and the bandwidth-intensive application checkout happens locally on the deployment machine. The final bit of improvement this could stand is to have the bzr checkout use export and not branch, but I think I'll have to alter the Capistrano's bzr plugin in order to do this.

Most sensible people are very wary of NFS and its potential for security holes. If you can at all help it, it's a good idea not to run NFS and portmap on a network interface with direct internet connectivity. However, this isn't always convenient. As I needed to have NFS sharing on a host exposed to the internet, I set about finding the various places I needed to firewall. The tools I typically use to verify I've done the right things are netstat -nap on the machine concerned, to check for listening processes, and nmap from remote hosts to sniff for open ports. Portmap and its associated programs mostly use 'tcpwrappers' for controlling access. The first step you ought to take in securing portmap is to ensure that your hosts.allow and hosts.deny files are set up to control access properly. In /etc/hosts.deny, deny access to allcomers:

mountd: ALL
statd: ALL
portmap: ALL
rquotad: ALL

Then in /etc/hosts.allow, let the good guys through (adjust for your network):

mountd: 192.168.0.
statd: 192.168.0.
portmap: 192.168.0.
rquotad: 192.168.0.

On top of this, however, you should firewall off the ports that these programs use. As I found out, this is not as easy as it sounds. Portmap assigns random ports for some of the services it starts. You can run rpcinfo -p to see the ports in use. An example run on one of my machines looks like this:

program vers proto   port
 100000    2   tcp    111  portmapper
 100000    2   udp    111  portmapper
 100003    2   udp   2049  nfs
 100003    3   udp   2049  nfs
 100003    4   udp   2049  nfs
 100003    2   tcp   2049  nfs
 100003    3   tcp   2049  nfs
 100003    4   tcp   2049  nfs
 100021    1   udp  32770  nlockmgr
 100021    3   udp  32770  nlockmgr
 100021    4   udp  32770  nlockmgr
 100021    1   tcp  32788  nlockmgr
 100021    3   tcp  32788  nlockmgr
 100021    4   tcp  32788  nlockmgr
 100005    1   udp   1005  mountd
 100005    1   tcp   1008  mountd
 100005    2   udp   1005  mountd
 100005    2   tcp   1008  mountd
 100005    3   udp   1005  mountd
 100005    3   tcp   1008  mountd
 100024    1   udp    863  status
 100024    1   tcp    866  status

Of these, nfs and portmapper always use the same ports, 2049 and 111, so ensure you block off these. What about the rest? Happily, there's a way to configure them to use constant ports so we can reliably firewall them. Life would be too easy if all this configuration was in the one place, so here's how to find the different places you need to change.

• nlockmgr: you're probably using the kernel NFS server, which means the port needs passing at module load time for the lockd module. Add this line into a new file, /etc/modutils/local-lockd

  options lockd nlm_udpport=32768 nlm_tcpport=32768

  Then run update-modules to recreate your /etc/modules.conf. The next time you boot these ports will be used for nlockmgr. If you've got the lockd statically compiled into your kernel, you'll need to pass these options as lockd.mnlm_udpport and lockd.nlm_tcpport to the kernel on boot.
• status: this is the port used by statd. There's also an outgoing port, on which statd sends outgoing status requests. You can configure them by altering STATDOPTS in /etc/default/nfs-common, e.g.

  STATDOPTS="--port 699 --outgoing-port 700"

• mountd: you can control the port used for mountd by editing /etc/default/nfs-kernel-server and altering RPCMOUNDOPTS, e.g.

  RPCMOUNTDOPTS="--port 962"

Finally, if you're running quotas, be sure to do something similar with RPCRQUOTADOPTS in /etc/default/quota. See also:

• SecuringNFS on the Debian Wiki
• Linux NFS HOWTO security chapter

Finally, I ought to note that I've written this up in case it helps anybody else. As with everything I write here, I make no warranty about its accuracy. Security is hard and obscure (but that's no reason not make our best efforts!)

There are just three days left to get discount registration for XTech WebDev London: our new one-day training event on Rails, Ajax, REST and web application design and development. It will be held in London on 31 October 2006. It's a great opportunity to get yourself and your team up to date with the latest web development technologies. Our speakers are real world practitioners who will tell you about the pitfalls as well as the promises. You will hear:

• Andy Budd on designing with web standards
• Jeremy Keith on Ajax, what it is, and its appropriate use
• Tom Coates on the building web applications as part of Web 2.0
• Leigh Dodds on the REST model for web applications and its benefits
• Matt Biddulph and Edd Dumbill on real-world Ruby on Rails

Additionally, everybody gets a copy of Cal Henderson's Building Scalable Web Sites, a buffet lunch and plenty of time to talk with the speakers and other attendees. We start at a developer-friendly time of 10am, which also gives plenty of time for those coming from further than London. There'll also be social events in the evening where you can continue networking and learning in more relaxed surroundings. Register now to attend at the cheaper price of 275.

I got an enormous amount out of the just-finished European FooCamp, with lots of thoughts sparking off and interesting things to consider. Jon Mountjoy proposed a theory to me that Web 2.0 and the enterprise weren't in fact as far apart as a naive observe might imagine. He reckons that mashups, tagging and the like do happen within the enterprise, and in fact are often solving harder problems than found in the wilds of the web. There is a lot in common between Web 2.0 and SOA (even aside from buzzword compliance factors). This is a theme I'd like to follow through. Who are the hackers on the inside of companies, and what stories do they have to tell? Gavin Starks from Global Cool really opened our eyes again to the problem of the environment, and introduced the interesting position that Global Cool are taking. If you want to do anything real right now to avoid catastrophic consequences, it's too late to wait for government initiatives to bear fruit. Private citizens must act too. And that's the aim of Global Cool: educating and lobbying the individual, not the government. I was struck, as were others, by the unfortunate irony that conferences have a big environmental cost in the travel involved, as we sat there among people from many countries. I want to now investigate how XTech could be better in this regard, through carbon offsetting and similar schemes. I guess being in Paris is already a good start, as trains are apparently only 25% as polluting as planes, though this still seems like a lot! Claus Dahl led an interesting and wide-ranging discussion about Second Life as a prototyping space for real life invention. Too many themes there to summarise neatly, but we did have an entertaining side discussion about Second Life's potential environmental impact due to CPU consumption and data centers. One suggestion was that objects and activities could be annotated in-world with their environmental cost. Simon Willison energetically explained OpenID, a decentralized identity system proposed by SixApart and already live in systems such as LiveJournal. It attempts to solve the problem of a username and password pair for every site you visit, without the controversy of centralisation suffered by projects such as Microsoft's passport. Simon demonstrated a proof of concept that I think will be a very neat answer to site providers who ask "why should I support OpenID?" (Sneak preview: because if you don't, it's going to be astonishingly easy for a middleman to provide it, and you wouldn't want that.) I also took time to learn about something I'd been interested in but not known much about, 3D printing and "fabbing". Simon Wardley led a great overview of current systems for 3D printing and their various attributes, and indicated where the current trends were going. It doesn't seem so unrealistic that there'll soon be affordable 3D printing bureaux similar to walk-in reprographic facilities like Kinkos. Plenty more went on that I've not got time to transcribe, but I think will flavour my thinking over the months to come. I was fortunate to be among some incredibly intelligent and welcoming people. My thanks to O'Reilly for putting this on, and to everyone else who went for being inspiring companions. Oh, one more thing. Belgians are excellent at confectionery.

Today I'm travelling to Belgium to take my part in the orgy of elitist conspiracy that is O'Reilly's European Foo Camp and open source convention. I've elected to undertake the journey by train.It is difficult to overemphasize how magnificent a thing the Eurostar service is. Were it left to our drab and utilitarian government alone, such a thing would never exist.Instead, in two and a half hours of clean, comfortable carriages and more than tolerable coffee I will be in Brussels, just a short tram ride away from my hotel. With the increasing difficulty and odiousness of air travel, things could hardly be more of a contrast.The price seems to me insanely cheap. My journey to Brussels and back costs under £60, less than my journey down to London from York in the first place.It almost makes you wish for the heady days of the Major government's flirtation with Europe. Life seemed simpler then. (We even had a prime minister who understood cricket, but that's another story.)EuroFOOFoo Camp is an event where O'Reilly Media invite a bunch of people to create an ad-hoc conference. For O'Reilly, it's a great way to take the pulse of earlier-than-thou early adopters and mad inventors, which in turn feeds their business. For the invitees, it's a great way to meet others, put your ideas out there, and get your mind expanded. For those outside the fold, exclusion has taken on an importance far out of proportion to its actual significance, which appears sadly inevitable.Although I was present at the US Foo a few weeks ago, illness meant I missed the bulk of it while recovering in a darkened room. So, I'm looking forward this time to playing a bigger part.One of the themes I'm seeing developing, and for which we intend to focus on at XTech 2007, is that of the increasing connectivity and blurring of distinction between the web and the world. Things to watch include Second Life, Thinglink, mobile, geotagging, ubiquitous computing.I'm also looking forward to hearing the low-down on Railsconf Europe from those who went. Sadly pressure of time meant I couldn't go, but the write-ups I've been seeing make it sound like an excellent event, and a great progression from the Chicago one.

I'm delighted to announce that registration is open for XTech WebDev London. This is a one-day training event for web developers, to be held on 31 October 2006. Our first event covers web standards, Ajax, REST and Rails, with a super-duper keynote from Tom Coates of Yahoo! You can find out more about the event on its website: speakers, schedule and benefits. What I want to do here is talk a bit about the backstory of XTech WebDev. I've been chairing the XTech web technologies conference, and before that, XML Europe, for five years. If you've ever been, you'll know it's an intense four days where the latest web and standards-based technologies are discussed. We typically hold the show in a European capital: we'll be in Paris in 2007. However, the full XTech show can be out of scope either in expense, location or duration for many. So, the idea for XTech WebDev was born. Take some of the best speakers and experience from the XTech conference, figure out what's most relevant to web developers at the coalface, and create a one-day event that's easy to get to and at the right cost. For our first event, we're featuring standards-based development, best practices for Ajax development, the REST style of developing web services, and Ruby on Rails. Along with that we'll have a keynote from Tom Coates challenging the way we think about our web applications. What we're aiming for is a convenient orientation day for web developers, which will enable you get a fix on the most important trends in web development happening right now. Although we'll be in London, we're not starting until 10am, which should leave plenty of time for people coming from further afar to be able to do the show in a day trip. I reckon it should be possible from as far away as Paris or Amsterdam, and even the north of England.... Registration is 275 if you sign up before 23 September, and space is limited, so be sure to sign up you and your team quickly. I really appreciate everybody's support as we branch out into this new event, and welcome all and any feedback and requests for future events.

You would be forgiven for thinking that using Mongrel clusters to serve Rails applications was only a good idea if you have Apache 2.2 installed, as this is what most of the instructions on the web advise. However, there are good reasons for still running Apache 2.0, one of them being that it's the most up to date version packaged in Debian and Ubuntu Linux. So, without mod_proxy_balancer, what can you do? A simple solution is to use the randomizing feature in mod_apache's rewrite map feature. Say for instance you had 3 Mongrel servers, running on ports 4000 to 4002 on localhost. First create a file map.txt containing these numbers:

ports  4000 4001 4002 

Then ensure the following directives are present in your virtual host configuration:

ProxyRequests Off
ProxyPassReverse / http://localhost:4000/
ProxyPassReverse / http://localhost:4001/
ProxyPassReverse / http://localhost:4002/
ProxyPreserveHost On
RewriteEngine On
RewriteMap  servers rnd:/path/to/your/map.txt
RewriteRule ^/(images stylesheets javascripts)/?(.*) $0 [L]
RewriteRule ^/(.*)$ http://localhost:$ servers:ports /$1 [P,L]

Of course, Apache config is complex and I advise you to test this properly — it's possible if you are not careful to leave your web server as an open proxy. Thanks to Matt Biddulph for pointing out this method to me. I've written it up as nobody else seemed to have done so thus far.

I'm pleased to report that Nickolay Shmyrev has taken over as the new maintainer of Monopod, my simple podcast client for the GNOME desktop.Monopod now has a new home page, and a publicly available Subversion repository. My thanks to Nickolay for taking this on.A new release is now available, which makes Monopod build with the latest ipod-sharp code. If you're in the market for a drop-dead simple podcast client, Monopod's still a great choice. 

To keep you reading all the way through, the best one's at the end.
1. I'm striking back out on my own againAfter a couple of years working full time in an office, I've decided it's the right time to take my own business, the Useful Information Company, further on. As the rest of this post illustrates, we'll be involved in web technology conferences, our own products, and Rails-based software development. I'm always looking for collaborators, comment and customers, so get in touch if any of this lot grabs you.
2. I'm organising an amazing web developer event in London, late OctoberUseful's first venture is XTech WebDev London. This is the first of a new type of event for XTech: a focused one-day training event for web developers. The idea is to focus on the best practice in web development that emerges from the cutting-edge work demonstrated in the regular XTech conference.This year, that means: Ajax, web standards, open data, REST and Ruby on Rails. Any web developer wanting inspiration and a view of the future should come along. London, UK. October 31, 2006. You can reserve your place now. (We're right-priced for your training budget, and start late enough that folks could make it from all over the UK and beyond without staying a night.)
3. The pace is hotting up for XTech 2007 in ParisMeanwhile, I'm busy putting together the call for participation and programme committee for XTech 2007, in Paris, France. Our theme is "The Ubiquitous Web." As keynotes, I'm pleased to welcome Adam Greenfield, Matt Webb and Jack Schulze.
4. I'll be off travelling shortly and reconnect with old and new friends Though a little daunted by the new face of air travel, I'm heading out to O'Reilly in Sebastopol at the end of this month to take part in FooCamp. One of my main aims is to seek out the ingredients required for a successful professional online community. In September I'll be putting in some time at EuroOSCON. Both visits will let me hook up with friends, many of whom I've not seen for a couple of years.
5. I'm on the programme committee for O'Reilly's Emerging Technologies 2007 conferenceThis one has me interested and engaged. Rael Dornfest is due to unveil the call for participation in a couple of weeks' time, and I'll give my take on the conference then. The show itself is March 26-29, 2007.
6. I have an exciting startup under the covers, in the area of conference and event managementOne of the things I've done a lot of over the last half-decade is organise, coax and bully people into presenting at conferences. I'm pouring what I've learned, and more besides, into a great product. You'll soon be bored of me talking about it.
7. I'm involved in taking Pharmalicensing into an exciting new phasePharmalicensing is an online exchange for intellectual property in the biotech and pharmaceutical world. I was part of its foundation in 1998, and am still involved. I will be part of a newly energized team of people pushing it forward into 2007. 8. I'm having a bit of a clean-out of projectsAlas, with so much going on, I need to cut out a few existing commitments. One of these things will be Monopod, my Mono-based podcast client for Linux. If I can't find anybody interested in its maintenance, I'll just hang the source code out there for anyone to pick up.
9. I want to get more energy put into DOAPOne of my long term projects I definitely don't want to cut out is DOAP, my project to describe software projects in RDF. It's had a slow but sure take-up over the last few years, and is finding its way into some significant projects. However, I do need a bit more energy for it, and one or two collaborators would certainly help. 10. Around Christmas-time, I'm going to become a father to twinsI've still not recovered from the shock. Rachael and I are going to be the proud, stunned, parents of a couple of bright shiny bundles of Human 2.0. Completely awesome, and I've absolutely no idea what to do! For now, we're just concentrating on throwing enough junk out to make room for them.

It's been a fun day today, the pre-conference warm up day for RailsConf.Over breakfast with Surj Patel and Matt Biddulph, we got to talking about debuggers and poking around inside Rails applications. With Rails being so new, I was intrigued in what happens when you hand a Rails application over to somebody. Does all the Rails magic help or hinder their ability to understand what's going on?What kind of ways are there, beyond documentation (which nobody writes), to communicate the workings of a Rails app? We thought that what might help would be some kind of graphical illustration of the flow of control, linked to a source viewer, that showed requests being processed. Rails is built in a convenient way for instrumentation and introspection, by virtue of the aggressive use of DSLs and Ruby's language features. Based on these, are there tools we can write to help people understand what a Rails application is doing?
I've not yet had enough experience of either handing off, or being handed, mature Rails apps to say for sure what's needed. But it's going to be a problem we all face when Rails sneaks further into the system. Java's redeeming quality in the enterprise is that it's damn hard to write anything one might consider idiomatic. As a consequence, there are predictable ways in which one can approach code written by somebody else, all other factors being equal. Will Rails idioms cause trouble for long-term maintainability?
Lunchtime included an interesting exchange with Rich Kilmer. Rich used to work for DARPA on RDF and OWL stuff, and has apparently written all manner of interesting Ruby code that processes RDF. It's a crime I'd not come across his work before, but it's all open sourced in the Semitar project. The project web page looks modest, but if Rich's description is anything to go by, it sounds a wonderfully appropriate way to approach programming for the semantic web.Finally, I notice that, as the day finishes, IBM developerWorks have published my Introduction to Rails for DB2 developers.RailsConf proper starts tomorrow. 

This Wednesday I'm heading out to Chicago to visit RailsConf. The full schedule has now been posted, and it looks like a pretty absorbing affair.It amuses me that US-based conferences often have evening sessions timetabled. In Europe, I've always preferred to leave evenings empty so people can eat, drink and socialise. But in big city hotel-land, I can understand the appeal of timetabling more of the day.Here's a selection of the talks I'm most interested in hearing: Internationalizing Rails (almost the number one question we got asked about Rails when we taught our tutorial at XTech), anything related to testing, Rails Application Optimization Techniques and Tools, Rails Deployment. Oh, and some guy's talking about his work at the BBC.I've just finished writing an article for IBM developerWorks introducing Rails to DB2 users. (I had surprisingly little problem getting DB2 up and running in a matter of minutes on my Ubuntu box.) IBM's DB2 integration for Rails is a great development, and it's nice to see them pushing forward with Rails as a platform. I'm hoping they'll post the article up before RailsConf starts.
Given a bit more hacking time, I'll be intrigued to see how DB2's XML support can play with Rails.I'll be staying at the conference hotel, and am very interested in meeting up with anyone building Rails apps of a decent scale, or looking for a project to work on. Do drop me an email.

Many advances have been made in agile software development. Frameworks such as Ruby on Rails embody agile principles by making software easy to write, easy to test, and above all, easy to change.If only we could say the same for the infrastructure on which we develop and deploy web applications. Not every application can be a Rails one, especially where it's been up and running for years. The systems we deploy on often rely on configuration files scattered all over the filesystem, and can be complex results of years of change.By extension, the systems we develop on often don't exactly mirror where we deploy. If we're lucky and careful, then we have a staging server which mirrors the live environment, but that's not too much of an advantage. Among other things, we need ways to evolve and refactor the live environment, and have our development environments easily track that.I'd like to call such an environment "agile infrastructure". Infrastructure that doesn't hamper developers, and allows live configurations to change and evolve. Infrastructure that allows new things to be tried with minimum cost, and can provide the best information possible to help future planning.Tools enable techniques, of course. It's a lot easier to be agile if you're programming in Rails rather than plain old PHP. So what are the tools enabling agile infrastructure?
Techniques I've found usefulWhile there's a long way to go, I'd like to describe some of the techniques I've been using to help create a flexible environment for developing a sizeable PHP/MySQL application.Operating systemAn operating system must be easy to bring into a known state with minimum interference. For this, I've found Ubuntu or Debian to be an ideal choice. Two of the main reasons include the constancy of stable releases and the fact that it's rare you need to stray outside the distribution's servers to get the software you need.DeploymentDeploying an application shouldn't break the cleanliness of your OS build. I prefer to package deployed applications into .deb files. This enables me to build on several advantages of the package management system:

• configuration file handling: deployed machines can keep individual config in /etc, which is preserved over software update.
• no random state: you know for sure exactly the state of the deployed application, no random files left hanging around.
• natural workflow: packages take a little bit of effort to build and deploy, which means it focuses developers on getting them right. If things do go wrong, it's very easy to roll back one version.

Source controlThe case for source control, thankfully, doesn't need making these days. Yet not every source control system is created equal. Developers shouldn't be constrained by source control, it should be cheap and easy to try new ideas and merge these in later.Not only cheap branching, but also easy merging, is required to keep development agile while still retaining the benefits of source control. Many people flock to Subversion these days, predominantly because it fixes some of CVS' more egregious misfeatures. However, merging can still be pretty difficult in Subversion.I prefer to use a system allowing easy merging, such as svk or bazaar. Because so many of us use laptops these days, disconnected operation is also a huge boon. Bazaar-NG offers both repository-oriented and completely decentralized operation, giving the best of both worlds. It also wins the competition for least setup overhead.VirtualizationPreviously a high-powered technology, cheap virtualization is now with us. Many identical virtual machines can be quickly created to enable testing and experimentation. Deployment to virtual machines can enable hardware independence for applications, reducing another big headache.Large organisations have it within their reach to bring new hardware online easily, and have invested much in management systems for it. Virtualization brings this in reach of small and one-man development teams.Desktop-based virtualizationSystems such as VMWare and Parallels untether developers from their desks. I use the OS X desktop daily for its productivity software, but an Ubuntu virtual machine for a large proportion of development work. A simple keypress lets me flick between the two. The advantages of multiple desktops to hand for web development are well known. (In fact, thanks to WINE and IES4Linux I can run Internet Explorer cheaply too from the same virtual machine).
Xen virtualizationAfter the initial novelty wears off, one of the most tedious tasks in the world is bringing new machines online. Combined with the tendency development environments have to get crufty as new ideas and tools are tried out, this makes for increasing disparity between the development and deployment environments.Wouldn't it be nice just to take a clean machine off the shelf, check out the source, and pick up again? Using Xen for Linux, this cheap virtualization is possible.Sadly, Xen isn't yet a packaged part of Ubuntu, but getting it up and running on Ubuntu Dapper isn't too hard. Warning: here's where things get pretty deep. Skip this bit if you're not interested in the nitty-gritty.I followed these steps:

• Followed instructions in the Ubuntu wiki to get the first domain (vm) up and running
  
• Installed the xen-tools package, which provides wrappers for easily creating virtual machines
• Adjusted some of the xen-tools configuration (/etc/xen-tools/hook.d/20-setup-apt) to set up for Ubuntu rather than Debian
• Once the virtual machine was made, adjusted its config to allow for the kernel initrd and configure the network bridge I was using
  

Getting over the DNS mountainIf you want it to be easy to bring new virtual machines up and down, you need to adopt a different approach to managing your DNS. You need to know how to predictably connect to a virtual machine. Yet it's going to get very boring and error prone to manage the IP address space manually in your DNS, or even to map the MAC addresses of your virtual machines in your DHCP configuration.
Help is at hand in the form of mDNS (also known as Rendezvous / Bonjour / ZeroConf). In the host machine, and in each virtual machine, I ensured the avahi-daemon and avahi-utils packages were installed, providing mDNS services. (You should also check that mdns is present in the hosts entry of /etc/nsswitch.conf).What all this does is allow the machines (virtual or otherwise) on the network to resolve names using mDNS. So if I create 3 VMs, alpha, beta and gamma, I can access these right away using the hostnames alpha.local, beta.local and gamma.local.Hey presto! Easily make machines appear and disappear without any need for sysadmin involvement. All the extra steps to add avahi installation can be easily scripted with xen-tools, to reduce the number of commands needed to birth a new machine to one.With this ease of creating new machines, it's much more straightforward to experiment with server topology and conduct experiments on server environments.ConclusionAgile development is necessarily constrained by the infrastructure on which it is conducted. The infrastructure itself is constrained by the tools and platforms of choice.By appropriate tool choice we can reduce the commitment and overhead of infrastructure. This enables developers to get on with the job they do best, and makes experimentation and evolution of infrastructure much simpler.When programming, it's dangerous to fall in love with your code, as the best solution may often involve throwing half of it away. The same hazard exists with infrastructure, with bizarre and awkward effects propagating back into code and operations. Get yourself a low commitment, agile environment, and you'll be able to keep up with the pace. 

If you missed being at XTech 2006, no need to worry, there's some great coverage out on various blogs right now.Suw Charman has some detailed transcripts of sessions she attended. Find them via the "related entries" bit of her XTech wrap-up post. I'd not had the pleasure of meeting Suw before last week, and I was enormously happy that she came to speak at the conference and contributed so generously in her blogging.(I also had a very interesting conversation with Suw about venues in London, which is all I'll say for now, but watch this space for news of a plot I'm cooking up for later this year.) Thomas Vander Wal has also written about his XTech experiences. It thrills me to bits that we were able to challenge and stimulate established web experts and newcomers alike.I'm really grateful to everybody who has blogged about XTech. It really improves the experience for everyone, and reaches out to those who were unable to attend. Through Planet XTech we were all able to get instant feedback and reflection on the conference. I've tried to read every word that has been written, good and bad, and will fold what I've learned into the planning for next year's event. And now is not the time to rest. XTech 2007 will be held in Paris, in May 2007. I will very shortly be announcing the theme and confirming exact dates and venue.

Two books have recently been published that I want to read.

• Rails Recipes (Chad Fowler)
  
• Building a Scalable Web Application (Cal Henderson)

The first of these I took delivery of instantly in PDF form, and a paper copy will make its way to me in due course so I have it as a handy reference.The second of these is going to take 12-14 days from Amazon (5-7 days if ordered through O'Reilly's UK distributor Wiley).
There's been a lot of talk on David Heinemeier Hansson's blog about PDF publishing, but to me it's simply a way of getting me the information I need quickly. Normally, I want the paper copy too.Another small but significant benefit is that PDFs weigh very little! Having just taught a Rails tutorial at XTech, I can vouch that there was no way we wanted to carry around 30+ copies of the Rails book on the offchance attendees wanted to buy it. Whereas some publishers have experimented with certain product lines available only as PDFs, I can't quite shake the feeling they're offering an inferior product in which they are not confident enough to commit to paper.My suggestion is that PDF and print is not an "either/or" choice, but an "and/or".

The move to better subpixel rendering in X windows continues. Tobias Wolf kindly pointed out to me these new patches from David Turner. Turner says "it's rather delicious" and I'm inclined to agree.
Applied to libXft and Cairo, they remove a lot of the ugly colour fringing from subpixel rendered fonts under Linux.David posts a screenshot, which looks great on my screen (if you have a CRT or different pixel ordering, it may look horrible for you -- the disadvantage of subpixel and screenshots!)Update: Tobias mentions another patch, which is needed to get best results. 

Regular readers will know I'm keen on getting good-looking fonts in Emacs under Linux. And so are a lot of other people, judging by how popular my Emacs/Xft posts have been. I have found out this is enough to drive some people to me sending nastygrams.

To: Edd Dumbill
Subject: whoareyou I don't know who you are, but... Emacs is a programmers editor. Sure, scalable fonts would be good for GNUEmacs, but they are not a necessity. If you want the wysiwyg experience, try XEmacs, I don't like XEmacs, but you are welcome to try it. I have used GNU/Emacs for the last 12 years as a code editor.  I like it just fine, and that is an understatement.  Leave it alone.

Well, it's finally arrived and here I am in the middle of it all.
Rails fun

The week kicked off with Matt and I teaching our tutorial on Ruby on Rails. It was the first time we've taught on that topic, so we were interested to hear the opinions of the attendees. We embarked on a fast-paced day-long tour of Rails features, with a large amount of live coding on screen.The aim was to give attendees an understanding of Rails as an environment for developing web applications, to let them see how fun it was to code (especially tests) and provide a bucket full of jumping off points for them to pursue their own investigations. With six or seven deployed Rails applications between us, we're in a good position to talk as real-world developers.
I think we pretty much succeeded. During the day we saw many places to improve the material and the flow, but the concept was sound. Teaching together meant we gave each other energy, humour and support. From the feedback, everybody was kept entertained and engaged as well as educated. Folks went away with the slides and the source code for the application we developed over the day. We thought about making our own course notes, but really there's nothing better than the Pragmatic Rails book, so there didn't seem much point in duplicating that effort.
We'd certainly like to do it again, and we're interested in visiting companies interested in Rails to bring their developer teams up to speed: we've already heard from one company attending the conference about that. So do get in touch if that interests you.KeynotesPaul Graham kicked off the conference with a provocative keynote comparing the conditions in the EU and US, and their suitability for stimulating startup companies. This has already sparked off a lot of discussion on the web, which is great to see. I'm really grateful to Paul for travelling a long distance to speak to us.We also heard from Jeffrey McManus of Yahoo! (I can never write "Yahoo!'s Jeffrey McManus" because the consequent train-wreck of punctuation upsets me). He shared the remarkable number of APIs and places where Yahoo! lets developers hook into their data and services. There's so much in there, I resolved to put some serious time aside to investigate what I could make use of.
CoverageThe site I set up for last year's conference, Planet XTech, is doing a great job aggregating blog coverage of XTech again this year. It's a great way for people here, and those following from a distance, to keep up with what's going on. Some folks are blogging really detailed notes, which is fantastic for the talks I've not been able to get to.Next yearIn a couple of weeks' time, I'll start thinking about next year's conference. I'll try to pull together what we've learned this year to make XTech even better. One thing we know already is that this year is our last in Amsterdam. We've been here three years and had a lot of fun. Next year, we're heading to Paris, which will be wonderful.Please do write to me with any comments and suggestions about XTech. One idea I'm playing with is the idea of a smaller related event later in the year, focused on educating people about web technologies.

It's now just one week until XTech 2006.This is the point that the whole of the last year has been leading up to for me. It's now I can let myself stop being stressed and start to let the excitement in.You know how sometimes you look back at stuff you've done, and go "wow!" -- that's pretty much where I am right now. I've run out of superlatives to apply to the speaker lineup. I've thrilled that we'll be joined by just about the entire Mozilla project, Paul Graham, Jeff Barr, Jeffrey McManus, huge chunks of the BBC brains trust, the smartest people in XML and the semantic web, Ajax pioneers and thinkers, top-class instructors and so much more.Last-minute XTech happenings of interest include:

• Google join the schedule line-up, talking about GData.
• We've put an advert for XTech on Ryan Carson's new magazine for web developers, Vitamin. I've been enjoying Ryan's straightforward approach to web business recently, so I hope this works out well.
• For your inner techie, web caching expert Mark Nottingham joins the XTech program, talking about what's needed to support fast delivery of today's more dynamic web applications.
• We've added a Developers' Corner to the exhibition, where anybody with a project and a laptop can set up to show off their stuff. With the calibre of people floating round, this is a great chance to find collaborators and maybe more.
• A downloadable iCal schedule so there's no excuse for missing anything.
  

Finally, just a note that it's never too late to come along. If you've not registered, just turn up on the day and pay on the door. It's an easy flight to Amsterdam, a short train ride to Centraal and a short walk to the hotel.See you there!